home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / LINUX / MATH_EMU.ZIP / MATH_EMU / README < prev    next >
Encoding:
Text File  |  1979-12-31  |  5.0 KB  |  161 lines
  1. FPU emulation code v0.6
  2.  
  3.  
  4. This is what you need to get Linux to work if you are not
  5. fortunate enough to own an 68881/2. The file 
  6.  
  7. /usr/src/linux/arch/m68k/kerlenl/traps.c
  8.  
  9. needs to be adjusted like I did in the included traps.c file.
  10. You will also need to adjust your bootstrap program to make the
  11. 68881 the default processor if no FPU is found.
  12. Also you will have to link math_emu.o to your kernel (of course ;-)
  13.  
  14. This program is based on the NetBSD FPU emulator.
  15. The original README is included below. Some changes made by me are:
  16.  
  17. -Added FSAVE/FRESTORE support (essential for Linux)
  18. -patches for supervisor mode; new trap handler
  19. -Linux compatible signal handling
  20. -bugfixes
  21. -added the following instructions:
  22.  FSIN,FCOS,FSINCOS,FTAN (more to follow)
  23.  
  24.  
  25.                     Paul Coene
  26.  
  27.  
  28.  
  29. -----------------------------------------------------------------------
  30. 1. LIST OF IMPLEMENTED AND UNIMPLEMENTED INSTRUCTIONS
  31.  
  32. This is the list of implemented and unimplemented FPU instructions.
  33. All 040's FP instructions except FSAVE and FRESTORE are implemented.
  34.  
  35. Type field = bit 8-6 of opcode word
  36.  
  37. 1-1. Implemented Instructions
  38.  
  39. Type=0: FMOVE (mem->FPr), FINT, FINTRZ, FSQRT, FABS, FNEG, FGETEXP,
  40.     FGETMAN, FDIV, FADD, FMUL, FSGLDIV, FSCALE, FSGLMUL, FSUB,
  41.     FCMP, FTST, FMOVE (FPr->mem), FMOVEM (FPr), FMOVEM (FPcr),
  42.     FMOVECR, FLOGNP1, FLOGN, FLOG10, FLOG2, FMOD, FREM
  43.  
  44. Type=1: FDBcc, FScc, FTRAPcc,
  45.  
  46. Type=2: FBcc (word, incl. FNOP)
  47.  
  48. Type=3: FBcc (long)
  49.  
  50. Type=4: none
  51.  
  52. Type=5: none
  53.  
  54. 1-2. Unimplemented Instructions
  55.  
  56. Type=0: FSINH, FETOXM1, FTANH, FATAN, FASIN, FATANH, FSIN, FTAN,
  57.     FETOX, FTWOTOX, FTENTOX, FCOSH, FACOS, FCOS, FSINCOS
  58.  
  59. Type=1: none
  60.  
  61. Type=2: none
  62.  
  63. Type=3: none
  64.  
  65. Type=4: FSAVE
  66.  
  67. Type=5: FRESTORE
  68.  
  69.  
  70. 2. WHAT ARE MISSING BESIDES UNIMPLEMENTED INSTRUCTIONS
  71.  
  72. Missing is Packed BCD support, but I do not feel any particular need
  73. for it.  But if anyone wants it, feel free to add the PBCD support;
  74. all we need is type conversion from PBCD external type to internal FP
  75. number format and vice versa.  No FP arithmetic is done in external
  76. formats (i.e. byte/word/long integers, single/double/extended IEEE FPs
  77. or PBCD); they are first converted into the internal format then used
  78. for calculations.
  79.  
  80.  
  81. 3. HOW TO ADD A NEW INSTRUCTION SUPPORT
  82.  
  83. Since we need not support FSAVE and FRESTORE operations, all
  84. instructions we have to implement are type 0, all of which are
  85. arithmetic operations.  It is particularly easy to add a new
  86. arithmetic instruction to the existing ones (not to say it is easy to
  87. write a "stable" function to perform floating point
  88. operations... that's entirely another matter).  In "fpu_emulate.c",
  89. there's a function fpu_emul_arith().  In it, there's a large switch()
  90. { case ... } which dispatch each instruction emulator function.  An
  91. emulator function of any type 0 arithmetic instruction follows this
  92. prototype:
  93.  
  94.     struct fpn *fpu_op(struct fpemu *fe);
  95.  
  96. Where fe is a pointer to a struct where frame, fpframe, and fetched
  97. operands are accessible.  That's right, you don't have to fetch the
  98. operands by yourself in you emulation funtion.  For instance, the parts
  99. calling FSQRT, FSUB, FADD and FTST look like:
  100.  
  101.     switch(word1 & 0x3F) {
  102. [...]
  103.     case 0x04:    /* fsqrt */
  104.         res = fpu_sqrt(fe);
  105.         break;
  106. [...]
  107.     case 0x28:    /* fsub */
  108.         fe->fe_f2.fp_sign = !fe->fe_f2.fp_sign; /* f2 = -f2 */
  109.     case 0x22:    /* fadd */
  110.         res = fpu_add(fe);
  111.         break;
  112. [...]
  113.     case 0x3A:    /* ftst */
  114.         res = &fe->fe_f2;
  115.         no_store = 1;
  116.         break;
  117. [...]
  118.     default:
  119.         sig = SIGILL;
  120.     } /* switch */
  121.  
  122. Here, fe->fe_f1 and fe->fe_f2 are fetched operands.  You can use
  123. fe->fe_f3 for storing the result, or you can return a pointer to
  124. either operand if you want to.  At any rate, you have to follow
  125. the following rules:
  126.  
  127.     1) A diadic instruction takes two operands fe->fe_f1 & fe->fe_f2.
  128.     2) A monadic instruction takes one operands fe->fe_f2 (NOT fe_f1).
  129.     3) Must return a pointer to struct fpn where the result is stored.
  130.     4) If exceptions are detected, set corresponding bits in fe->fe_fpsr.
  131.     The rest is taken care of in fpu_emul_arith().
  132.     5) Condition code need not be calculated.  It's taken care of in
  133.     fpu_emul_arith().
  134.  
  135. Actually, after above was written, stubs for the missing functions are
  136. added to the source, so you do not have to change fpu_emul_arith() at
  137. all.  Function names and prototypes are in fpu_arith_proto.h, and all
  138. (except fpu_sincos()) follows the rules above.
  139.  
  140.  
  141. 4. OTHER POSSIBLE IMPROVEMENTS
  142.  
  143. 4-1. THINGS NOT MENTIONED HERE
  144.  
  145. I'm sure we could use any kind of improvements from anyone.  The
  146. following thing(s) is(are) what I can think of off hand.
  147.  
  148. 4-2. SPEED
  149.  
  150. Probably the precision (115-bit significand) derived from Sparc FPE is
  151. not necessary and slowing things down.  Reducing precision to
  152. something which would make more sense in the context of m68k, like
  153. 67-bits (64 + guard/round/sticky bits), would not be trivial since
  154. reference to 4 significand words is scattered all over the code
  155. whether Sparc-derived or not.  But it would be a good project.
  156.  
  157. Also, addition/subtraction of significand (= long integer) could be
  158. done in assembly instead of C as is currently done.  This might speed
  159. things up a little bit.
  160.  
  161.